Anwendungen optimieren mit dem Index Tuning Wizard

Das mit diesem Profiler-Tool aufgezeichnete Protokoll, das den tatsächlichen Workload der Datenbank wiedergibt, kann in einer Vielzahl von Situationen nützlich sein. Wir wollen nun einen Blick darauf werfen, wie man Profiler einsetzt, um vom Index Tuning Wizard zu verwendende Daten zu sammeln, und wie man diese Tools zum Debuggen von Applikationen benutzen kann.

Einsatzgebiete

Das Profiler-Tool kann in allen Phasen des Entwicklungszyklus einer Datenbank von Nutzen sein. Beispielsweise kann man es in der Anfangsphase als Hilfe beim Debuggen einsetzen sowie um schrittweise zu prüfen, wie und wann Ihre Anwendung abgespeicherte Prozeduren oder andere SQL-Anweisungen aufruft. In einem Projekt, bei dem ich vor kurzem mitgewirkt habe, haben wir Profiler benutzt, um SQL-Anweisungen zu identifizieren und die Reihenfolge zu ermitteln, in der die Anwendung diese aufrief, wenn sie mit einer kompilierten Komponente arbeitete, die beim Aufruf der Datenbank immer hängen blieb. Die Verwendung dieses Tools half uns beim Aufspüren eines Programmierfehlers, so dass wir unsere Anwendung korrigieren konnten.

Im weiter fortgeschrittenen Stadium des Entwicklungsprozesses kann Profiler dabei helfen, durch Load-/Stress-Tests Engpässe in der Anwendung aufzuspüren. Man kann das Tool auch für die Überwachung regulärer Aktivitäten benutzen, für Sicherheits-Audits und zum Aufspüren anderer Performance-Hindernisse (z.B. schlecht konzipierte Abfragen).

In Profiler muss man entscheiden, was man aufzeichnen will, und überlegen, wo man die aufgezeichneten Aktivitäten der Datenbank abspeichert. Man kann die Aufzeichnungen entweder in einer Datenbanktabelle oder einer Datei speichern. Wenn man sich für eine Tabelle entscheidet, kann man auch eine maximale Anzahl von zu speichernden Zeilen festlegen. Auf diese Weise kann Profiler schnell große Datenmengen in einem stark benutzten System aufzeichnen. Aber genau aus diesem Grund wird man auch die Menge der von Profiler aufzuzeichnenden Daten begrenzen wollen.

Man kann das Profil auch in einer Protokolldatei speichern. Bei dieser Option kann man einstellen, dass die Informationen in der Datei bei Erreichen einer bestimmten Dateigröße überschrieben werden, wodurch die Gesamtgröße der Datei begrenzt wird. Man kann auch festlegen, wo die Protokollierung verarbeitet werden soll. Das ist ungefähr so, als wenn man den Cursor in einer Anwendung entweder auf dem Client oder auf dem Server ausführen lässt. Bei einem Produktionssystem möchte man den Server wahrscheinlich nicht so stark belasten, also dürfte die clientseitige Verarbeitung die bessere Wahl sein.

Wenn man sich zwischen diesen beiden Optionen entscheidet, sollte man vor allem die Auswirkungen auf die Performance der Datenbanken/Anwendungen im Auge behalten. Wie bei den meisten Protokollen ist das Speichern in einer Datei für das System weniger belastend als das Speichern in einer Datenbanktabelle. Für stark frequentierte Produktionssysteme dürfte eine Protokolldatei also die bessere Wahl sein.